1. Field of the Invention
This invention relates to computer software, and more particularly to the dynamic loading of remote classes.
2. Description of the Related Art
In a distributed computing environment, code (e.g. an application, applet, servlet, executable code fragment, or any other computer-executable code) on one machine or virtual machine (e.g. e.g. Java Virtual Machine (JVM)) can be run on different machines and/or different virtual machines (e.g. JVMs). Thus, code or code fragments may be transferred between machines and/or virtual machines. For object-oriented code, a machine or virtual machine may rely on the dynamic loading of classes to run the code remotely.
Class loaders are one of the cornerstones of virtual machine architectures such as the JVM architecture. Class loaders may enable a virtual machine to load classes without knowing anything about the underlying file system semantics, and may allow applications to dynamically load classes such as Java™ classes as extension modules. For example, JVM has an embedded class loader called the default or system class loader. The default class loading behavior in the JVM is to load the class file from a specified location (specified in a class path) into the memory and to execute the byte code as and when the request comes in for the particular class. The default class loader may cache the class once it loads the class.
Virtual machines such as JVM may provide a facility by which a user can introduce a custom class loader. For example, in JVM, a hook is provided to the loading mechanism through the custom class loaders. Programmatically speaking, class loaders are ordinary objects that may be defined in code (e.g. Java™ code). In Java™, class loaders are instances of subclasses of abstract class Classloader.
In Java, a custom class loader may load a class before or after the default class loader attempts to load the class. Therefore, certain policies pertaining to loading classes, maintenance, fetching classes, etc. may be implemented by the custom class loader. The custom class loader may also, for example, specify the remote location from which the classes are loaded, and/or assign appropriate security. Class loaders may be used to control security of the classes loaded. For example, a custom class loader may check for a valid signature for the class before loading it and making it available for other objects to use. Class loaders may be used in applets to restrict loading of classes not on the system class path.
In Java™, classes and interfaces are dynamically loaded, linked, and initialized. Loading is the process of finding the binary form of a class or interface type with a particular name and constructing, from that binary form, a Class object to represent the class or interface. For example, a class or Interface C's loading is triggered by another class or interface D, which references C through its runtime constant pool. Class or interface loading may also be triggered by D invoking methods in certain Java™ class libraries such as Reflection. Once a class is loaded, it is linked and resolved. Linking involves verifying and preparing a class, its direct superinterfaces, its direct superclass and its element type (if it is an array type). The process of dynamically determining concrete values from symbolic references in the runtime constant pool is referred to as resolving or resolution.
The above information on class loaders, class loading, and class reloading refers to the Java™ programming language and to the Java™ Virtual Machine (JVM) architecture as an example of an implementation of class loaders, loading, and reloading. This information, however, may be relevant to other architectures, programming languages, environments including virtual machine environments, platforms, applications, application servers and/or implementations of class loaders.
In Java, to use a class, the class has to be in the class path of the default class loader, or alternatively a custom class loader may be provided. Custom class loaders, however, may conflict with the use of other class loaders, including the default class loader. For example, classes remotely loaded by a custom class loader may conflict with classes normally available through the default class loader. Therefore, it is desirable to provide a mechanism to remotely load all classes needed to run, for example, an application in a distributed computing environment through the default class loader, thus avoiding the use of custom class loader to remotely load the classes.
JXTA
JXTA technology is a set of open protocols that allow any connected device on the network ranging from cell phones and wireless PDAs to PCs and servers to communicate and collaborate in a P2P manner. JXTA peers create a virtual network where any peer can interact with other peers and resources directly even when some of the peers and resources are behind firewalls and NATs or are on different network transports. In JXTA, every peer is identified by an ID, unique over time and space. Peer groups are user-defined collections of entities (peers) that share a common interest. Peer groups are also identified by unique IDs. Peers can belong to multiple peer groups, can discover other entities and peer resources (e.g. peers, peer groups, services, content, etc.) dynamically and can also publish themselves and resources so that other peers can discover them.